Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added realistic movement trail #5702

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Added realistic movement trail #5702

wants to merge 5 commits into from

Conversation

AverageNerdz
Copy link
Contributor

Brief Description of What This PR Does

This PR adds a visual enhancement for microbe movements, the core class of this implementation is the c++ "Ripple" class that generates smooth, fading trails behind all moving microbes, then the scene emits bubble particles around the trail, all particles are generated by a shader with the same name as the new class. Under the hood the implementation uses triangle strips for the mesh generation it automatically cleans old trail points based on age and distance.

Related Issues

Progress Checklist

Note: before starting this checklist the PR should be marked as non-draft.

  • PR author has checked that this PR works as intended and doesn't
    break existing features:
    https://wiki.revolutionarygamesstudio.com/wiki/Testing_Checklist
    (this is important as to not waste the time of Thrive team
    members reviewing this PR)
  • Initial code review passed (this and further items should not be checked by the PR author)
  • Functionality is confirmed working by another person (see above checklist link)
  • Final code review is passed and code conforms to the
    styleguide.

Before merging all CI jobs should finish on this PR without errors, if
there are automatically detected style issues they should be fixed by
the PR author. Merging must follow our
styleguide.

@@ -0,0 +1,32 @@
shader_type spatial;

uniform sampler2D bubble_noise;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

camelCase naming should be used in Thrive shaders.

Comment on lines -48 to -49
process_priority = 2
cast_shadow = 0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have changed script order priority and shadow settings for the membrane. If these are intentional, could you explain why these are necessary?

Comment on lines +98 to +101
layers = 2
material_override = SubResource("ShaderMaterial_2")
cast_shadow = 0
mesh = SubResource("BoxMesh_1")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the reason behind changing the engulf mesh and the mucocyst mesh (I won't comment on that separately)?

Copy link
Member

@hhyyrylainen hhyyrylainen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On reviewing the code here, I no longer think that this is in any way necessary to write in C++. We already do very similar geometry updating in C# so I don't think this deserves any such special consideration. Especially as you are using the mesh surface tool which has the same exact API from C# as it does from C++ (so this doesn't even take advantage of any special optimizations that only C++ could do). I think it would be probably a better idea to implement the ripple effect as a single C# ECS system that uses a single multimesh to draw all of the effects (or direct geometry buffers that are updated), because I think it should be possible to use a multimesh instance with a sphere model to draw all of the cell's trails with a single draw call. Writing that in C# should be even overall faster than this not super polished approach (I have many more small tweak comments but I'll refrain from making them until the big architecture picture is worked out, like for example how the particle emitter is manually positioned even though it is already scene attached so that should be totally unnecessary).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In progress
Development

Successfully merging this pull request may close these issues.

2 participants